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Commissioner for Patents 
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APPEAL BRIEF 

L REAL PARTY IN INTEREST 
This application is assigned to International Business Machines Corporation, of Armonk, 
New York. 

n. RELATED APPEALS AND INTERFERENCES 
There are no related appeals or interferences. 



IH STATUS OF CLAIMS 
Claims 1-31 are pending in the Application. All pending claims stand rejected, and are 
now on appeal. 



IV. STATUS OF AMENDMENTS 
No amendments have been filed prior to or subsequent to final rejection (Paper No. 4). 
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V, SUMMARY OF CLAIMED SUBJECT MATTER 

Applicants' invention is generally directed to a method of dynamically modifying a cluster 
communication parameter used in connection with communicating data between nodes in a 
clustered computer system. 

Clustered computer systems rely on multiple individual computers, or nodes, which are 
networked together to present a single system image. Moreover, clusters are typically used in 
highly available/fault tolerant applications where system availability is of paramount concern. 
(Application, p. 1). Within such systems, it maybe desirable in many circumstances to modify 
certain low-level communication parameters used in the communication of messages between 
nodes. Due to the desirability of maintaining system availability, as well as the need to 
coordinate the operation of all of the nodes in a cluster, changing such parameters presents a 
specific problem that is somewhat unique to clustering. 

Specifically, separate copies of a communication parameters are typically maintained on 
each node in a cluster, thus requiring each copy of a particular communication parameter to be 
modified on each node whenever a modification to the parameter needs to be made. 
Furthermore, in many instances, reliable operation of a cluster requires that all copies of a given 
parameter be consistent with one another at all times. Otherwise, one node may operate in one 
manner on the assumption that the parameter is set to one value, while another node may operate 
in an entirely different manner on the assumption that the parameter is set to another value. 

Traditionally, the only way that it could be ensured that all copies of a given parameter 
were modified in a coherent fashion was to take every node off-line, manually change the local 
copy of the communication parameter on each node, and then restart each node. Doing so, 
however, often required that not only individual nodes, but the entire cluster, be inactive for at 
least some period of time. In many high availability applications, however, it is desirable for 
there to be absolutely no system downtime if at all possible. As a result, a cluster communication 
parameter change implemented in such a fashion is antipathetic to the goal of providing 
continuous availability in a clustered computer system. (Application, pp. 3-4). 
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Embodiments consistent with the invention address this problem by providing a method 
for dynamically modifying a cluster communication parameter via a distributed protocol whereby 
individual nodes locally confirm initiation and status information for every node participating in 
a parameter modification operation. (Application, p. 5). By doing so, individual nodes are also 
able to locally determine the need to undo locally-performed parameter modifications should any 
other node be incapable of performing a parameter modification. 

As discussed, for example, at pages 3 and 4 of the Application, cluster communication 
parameters are typically low-level communication parameters that control how each node 
operates in a clustered computer system. Put another way, these communication parameters 
typically define the protocol that a node uses to communicate with other nodes and/or the format 
of the messages being communicated between such nodes. 

Various examples of cluster communication parameters are set forth at page 12, line 30 to 
page 13, line 1 1 , of the Application, including, for example, "heartbeat parameters used to 
confirm the liveliness of interconnections between nodes in a cluster, e.g., heartbeat message 
time out, heartbeat acknowledgment message time out, heartbeat frequency or interval, heartbeat 
failure threshold, heartbeat acknowledgment failure threshold, receive/send timer ratio, etc." In 
addition, several other types of communication parameters are identified, including, for example, 
"maximum fragment sizes, message retry timer value, maximum message retry time, send queue 
overflow threshold, message send window size, etc." 

With respect in particular to cluster communication parameters such as heartbeat 
parameters, certain embodiments enable such parameters to be dynamically modified by 
configuring a sending node to send a heartbeat message to a receiving node, with the heartbeat 
message indicating that a heartbeat parameter is to be modified. In response to the heartbeat 
message, the receiving node may then send an acknowledgment message to the sending node that 
indicates whether the heartbeat parameter has been modified in the receiving node. Further, 
modification of the heartbeat parameter in the sending node may be deferred until the 
acknowledgment message from the receiving node indicates that the heartbeat parameter has 
been modified in the receiving node. (Application, pp. 5-6). 
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Independent claims 1 , 7, 1 2, 1 3, 1 9, 26 and 3 1 are at issue in this appeal. A summary of 
the subject matter of these claims has been provided above. Specific support for each of these 
claims is presented below, as required by 37 CFR 41.37(c)(l)(v). 

Claim 1 recites a method of dynamically modifying a cluster communication parameter in 
a clustered computer system, which includes: (a) initiating a cluster communication parameter 
modification by transmitting a message to a plurality of nodes in the clustered computer system 
(Application, page 14, lines 27-29, Fig. 5, block 76); (b) locally confirming, within each node, 
receipt of the message by each of the plurality of nodes (Application, page 15, lines 9-13, Fig. 6, 
block 106); (c) in response to confirming receipt of the message by each of the plurality of 
nodes, invoking a local cluster communication parameter modification operation on each node 
(Application, page 15, lines 11-13, Fig. 6, block 108); (d) transmitting from each node a status 
of the local cluster communication parameter modification invoked on that node (Application, 
page 15, lines 18-24, Fig. 6, blocks 1 12, 116); (e) locally detecting, within each node, an 
unsuccessful status for the local cluster communication parameter modification on any node 
(Application, page 15, lines 25-28, Fig. 6, block 118); and (f) in response to detecting an 
unsuccessful status for any node, locally undoing, in each node for which the local cluster 
communication operation was performed, the local cluster communication parameter 
modification operation performed on that node (Application, page 1 5, lines 28-32, Fig. 6, block 
120). 

Claims 7, 12 and 13 recite programs that perform the various steps set forth in claim 1, 
and as such, the Board may refer to the above summary of claim 1 as evidence of the support for 
claims 7, 12 and 13. 

Claim 19 recites a method of dynamically modifying a heartbeat parameter in a node 
among a plurality of nodes in a clustered computer system, where the plurality of nodes includes 
first and second nodes, the first node configured to send a heartbeat message to the second node, 
and the second node configured to send an acknowledgment message to the first node in response 
to receiving the heartbeat message (Application, page 1 8, lines 1 -3, Fig. 7, nodes D and U). The 
claimed method includes: (a) sending a heartbeat message from the first node to the second 
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node, the heartbeat message indicating that a heartbeat parameter is to be modified (Application, 
page 20, lines 22-24, Fig. 10, blocks 204-206); and (b) deferring modification of the heartbeat 
parameter in the first node until receipt of an acknowledgment message sent from the second 
node to the first node that indicates that the heartbeat parameter has been modified in the second 
node (Application, page 21, line 22 to page 22, line 2, Fig. 12, blocks 212, 216 and 218). 

Claims 26 and 31 recite programs that perform the various steps set forth in claim 19, and 
as such, the Board may refer to the above summary of claim 19 as evidence of the support for 
claims 26 and 31. 

VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 
Claims 1-3 1 stand rejected under 35 U.S.C. § 102(a) as being anticipated by U.S. Patent 
No. 6,108,699 to Moiin (hereinafter Moiin). 

VH. ARGUMENT 

Applicants respectfully submit that the Examiner's rejections of claims 1-31 are not 
supported on the record, and should be reversed. 

A. Claims 1-31 were improperly rejected as being anticipated by Moiin . 

The Examiner argues that Moiin anticipates all of claims 1-3L Anticipation of a claim 
under 35 U.S.C. §102, however, requires that "each and every element as set forth in the claim is 
found, either expressly or inherently described, in a single prior art reference." Verdegaal Bros., 
Inc. v. Union Oil Co., 2 USPQ2d 1051, 1053 (Fed. Cir. 1987), quoted in In re Robertson. 
49 USPQ2d 1949, 1950 (Fed. Cir. 1999). Absent express description, anticipation under 
inherency requires extrinsic evidence that makes it clear that "the missing descriptive matter is 
necessarily present in the thing described in the reference, and that it would be so recognized by 
persons of ordinary skill." Continental Can Co. v. Monsanto Co.* 20 USPQ2d 1746, 1749 (Fed. 
Cir. 1991), quoted in In re Robertson at 1951. "Inherency, however, may not be established by 
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probabilities or possibilities. The mere fact that a certain thing may result from a given set of 
circumstances is not sufficient." Continental Can at 1749, quoted in In re Robertson at 195 1. 

Applicants respectfully submit that Moiin does not disclose the various features recited in 
claims 1-31, and as such, the rejections thereof should be reversed. Applicants will hereinafter 
address the various claims that are the subject of the Examiner's rejection in order. 

Claim 1 

Turning first to independent claim 1, this claim recites a method of dynamically 
modifying a cluster communication parameter in a clustered computer system. The method 
includes initiating a cluster communication parameter modification by transmitting a message to 
a plurality of nodes in the clustered computer system, locally confirming, within each node, 
receipt of the message by each of the plurality of nodes, in response to confirming receipt of the 
message by each of the plurality of nodes, invoking a local cluster communication parameter 
modification operation on each node, transmitting from each node a status of the local cluster 
communication parameter modification invoked on that node, locally detecting, within each 
node, an unsuccessful status for the local cluster communication parameter modification on any 
node, and in response to detecting an unsuccessful status for any node, locally undoing, in each 
node for which the local cluster communication operation was performed, the local cluster 
communication parameter modification operation performed on that node. 

Of note, therefore, claim 1 is specifically focused upon a method of dynamically 
modifying a cluster communication parameter . Furthermore, it should be noted that the various 
steps in the claimed method involve a cluster communication parameter modification . 

Applicants respectfully submit that Moiin does not disclose this combination of features, 
and as such, the Examiner has failed to meet the burden required to sustain a rejection under 35 
U.S.C §102(a). 

Moiin> in particular, discloses at the most the modification of a parameter associated with 
cluster membership, which is appreciated by one of ordinary skill in the art as being a distinctly 
different concept from a cluster communication parameter within the scope of claim 1. As 
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discussed, for example, at pages 4 and 5 of the Application, cluster communication parameters 
are typically low-level communication parameters that control how each node operates in a 
clustered computer system. Put another way, these communication parameters typically define 
the protocol that a node uses to communicate with other nodes and/or the format of the messages 
being communicated between such nodes. 

Various examples of cluster communication parameters are set forth at page 12, line 30 to 
page 13, line 1 1, of the Application, including, for example, ir heartbeat parameters used to 
confirm the liveliness of interconnections between nodes in a cluster, e.g., heartbeat message 
time out, heartbeat acknowledgment message time out, heartbeat frequency or interval, heartbeat 
failure threshold, heartbeat acknowledgment failure threshold, receive/send timer ratio, etc." In 
addition, several other types of communication parameters are identified, including, for example, 
"maximum fragment sizes, message retry timer value, maximum message retry time, send queue 
overflow threshold, message send window size, etc." 

Of note, all of these examples of cluster communication parameters address operational 
characteristics of a clustered computer system that are of a substantially different nature from 
cluster membership. None of these exemplary communication parameters control which nodes in 
a clustered computer system transmit or receive messages, or any other concept related to cluster 
membership. 

Applicants respectfully submit that Moiin does not disclose the dynamic modification of 
any clustering-related parameter that can be analogized to a "cluster communication parameter" 
consistent with the invention. Specifically, Moiin discloses, at the most, the concept of a 
"reconfigure message" {see, e.g., col. 2), which is merely used to add or remove nodes to or from 
a cluster. In connection with the processing of such messages, parameters are interchanged 
including a cluster size N and a cluster list or vector V, with the former parameter simply storing 
the number of nodes identified in node list V. (col. 5, lines 32-46). Beyond this, however, the 
reference is entirely silent with respect to the particular messaging protocols utilized to manage 
node membership. 
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Neither the cluster size, nor the cluster list or vector, associated with the reconfigure 
messages of Moiin corresponds to a "cluster communication parameter" within the context of 
claim 1 . Both disclosed parameters in Moiin relate to cluster membership (which arguably 
discloses which nodes participate in communications); however, neither relates to how such 
communications occur between nodes. Indeed, the remainder of Moiin is entirely silent with 
respect to the particular protocols used to communicate between nodes, other than the fact that 
the nodes are interconnected by a conventional ethemet network, (col 5, lines 14-18). 

Given that neither a cluster size nor a cluster list corresponds to a "cluster communication 
parameter", Applicants respectfully submit that Moiin cannot be read to anticipate claim L 

In rebuttal, the Examiner makes three principal arguments in the Final Office Action 
dated June 7, 2004. First, the Examiner argues that the concept of a "cluster communication 
parameter" is found in the preamble, and thus is not entitled to patentable weight. However, 
even the case cited by the Examiner in support notes that the preamble is entitled to weight when 
the body of the claim depends on the preamble for completeness. In claim 1, several steps recite 
a "cluster communication parameter modification" operation performed on each node, and as 
such, the Examiner cannot simply ignore the nature of the parameters at issue in the claim as 
being "communication" parameters. 

Second, the Examiner argues that Moiin teaches modifying a cluster communication 
parameter by virtue of modifying cluster membership. Presumably, the Examiner's argument is 
founded upon the fact that if cluster membership changes, the "parameters of communication" 
are also changed or modified, i.e., the communications change de facto because different 
membership presumes a different set of nodes transmit and receive messages. However, the fact 
that which nodes communicate in a cluster happens to change as a result of a change in 
membership does not turn a membership-related parameter into a communication parameter. 

Furthermore, the concept of "membership" has a unique connotation in the clustering art, 
and is considered by those of ordinary skill in the art to be an entirely different concept from 
communication. Rather, membership is more related to the organization of logical entities 
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(nodes) in a cluster, rather than the underlying protocol of how those nodes communicate with 
one another. 

Third, the Examiner argues that Applicants are reading the specification into the claim. 
However, Applicants have cited the specification only for the purpose of interpreting the term 
"cluster communication parameter." Applicants have chosen to define the term in such a manner 
that one of ordinary skill in the art would recognize is entirely separate from the concept of 
membership, and to this extent, the citations to the specification are relevant in this regard. 

Therefore, Applicants respectfully submit that the Examiner's rejection of claim 1 should 
be reversed. Moreover, given that Moiin has no appreciation for the dynamic modification of 
communication parameters in a clustering environment, Applicants respectfully submit that claim 
1 is non-obvious over Moiin as well. 

Moiin simply does not appreciate any of the problems associated with modifying cluster 
communication parameters in an active clustered computer system. Moiin expects the messaging 
operations occurring between nodes to occur in an orderly manner, but there is absolutely no 
disclosure in the reference directed to how one could change any messaging operations through 
dynamic modifications to communication parameters that control how those messaging 
operations are performed. Accordingly, Applicants submit that one of ordinary skill in the art 
would not look to Moiin and derive from the disclosure of the reference a method of dynamically 
modifying a cluster communication parameter. 

Indeed, as noted above cluster membership is a completely different concept from cluster 
communication protocols, presenting entirely different problems requiring substantially different 
solutions. Among other unique problems, dynamic modifications to cluster communication 
parameters must be cognizant of the fact that active communications are continually being 
performed in an active clustering environment, and that the change-over to a new cluster 
communication parameter must be handled in an orderly fashion and with minimal interruption 
in messaging traffic. In contrast, changes in cluster membership are rather infrequent events, as 
even admitted at col. 8, lines 2-5 of Moiin, so the concern with interruptions in messaging 
capability are simply not present for changes to membership-related parameters. 
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Applicants therefore submit that claim 1 is also non-obvious over Moiin, Passage of 
claim 1 to allowance is therefore also respectfully requested. 

Claim 2 

Next, with respect to claim 2, this claim depends from claim 1, and specifies that the 
cluster communication parameter comprises a heartbeat parameter. In rejecting claim 2, the 
Examiner relies on col. 14, lines 26-34 of Moiin. However, this passage merely describes the use 
of heartbeat messages. There is no disclosure in the reference of making any changes to any 
parameter associated with such heartbeat messages. Indeed, given that the dynamic changes 
being made in the various routines disclosed in Moiin are all directed to changes in membership . 
Applicants respectfully submit that these routines do not disclose or suggest any dynamic 
modifications to a heartbeat parameter. 

The Examiner apparently argues in the Final Office Action dated June 7, 2004 that simply 
changing the membership of a cluster constitutes a change in a heartbeat parameter, since a 
change in membership would result in a different set of nodes sending and receiving heartbeat 
messages. Applicants respectfully submit, however, that just because a change in some 
parameter that is unrelated to heartbeat messages happens to result in a change to how many 
heartbeat messages are sent and received does not turn that parameter into a "heartbeat 
parameter. 1 ' Computers, particularly clustered computers, are complex systems, and a change to 
one aspect of a system very frequently results in indirect changes throughout the system. 
Applicants submit that the indirect affect that a change in membership has on how many 
heartbeat messages are sent is insufficient to establish that Moiin discloses the dynamic change to 
a "heartbeat parameter" as required by claim 2. 

Applicants therefore respectfully submit tfrat claim 2 is novel over Moiin, and that the 
rejection of claim 2 should be reversed. Moreover, Applicants respectfully submit that the 
Examiner has failed to establish any motivation to modify Moiin to dynamically change 
communication parameters such as heartbeat parameters, as noted above in connection with 
claim 1. Passage of claim 2 to allowance is therefore also respectfully requested. 
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Claim 3 

Next, with respect to claim 3, this claim depends from claim 1, and specifies that the 
cluster communication parameter is selected from a group consisting of: 

heartbeat message time out, heartbeat acknowledgment message 
time out, heartbeat frequency or interval, heartbeat failure 
threshold, heartbeat acknowledgment failure threshold, 
receive/send timer ratio, maximum fragment size, message retry 
timer value, maximum message retry time, send queue overflow 
threshold, message send window size, and combinations thereof 

As noted above in connection with claim 2, Moiin's disclosure of heartbeat messages falls 
far short of disclosing the dynamic modification of heartbeat or other communication-related 
parameters. Each enumerated item recited in claim 3 is an example of a communication-related 
parameter, and the disclosure of membership modifications in Moiin is insufficient to anticipate 
the concept of dynamically modifying any of these enumerated items, as noted above in 
connection with claim 1 . 

Furthermore, the Examiner apparently argues in the Final Office Action that a change in 
membership would result in a change in a heartbeat or other enumerated parameter. However, 
Applicants can find no support in Moiin for this assertion. To establish anticipation of claim 3, 
the Examiner would be required, in the least, to establish that Moiin teaches specifically 
changing one of the enumerated parameters. The Examiner has failed to do so in this case. 

In addition, the Examiner's argument that a change in membership somehow has an 
indirect influence on communication-related parameters in connection with the other rejected 
claims in effect supports the novelty of claim 3. It is only because the Examiner can find no 
specific communication-related parameters that are changed in Moiin that the Examiner has to 
rely on the indirect effect of a membership change to support the anticipation rejections of these 
other claims. The Examiner has made no effort to show where in the reference a direct change to 
one of the enumerated parameters is made in Moiin. Indirect effect on a communication-related 
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parameter, however, falls short of disclosing a specific and direct change to that parameter (a 
"cluster communication parameter modification"), as would be required to anticipate claim 3. 

Applicants therefore respectfully submit that claim 3 is novel over Moiin, and that the 
rejection of claim 3 should be reversed. Moreover, Applicants respectfully submit that the 
Examiner has failed to establish any motivation to modify Moiin to dynamically change any of 
the enumerated communication parameters, and as such, claim 3 is patentable over the prior art 
of record Passage of claim 3 to allowance is therefore also respectfully requested 

Claims 4-6 

Claims 4-6 are not separately argued. 

Claims 7. 12 and 13 

Next, with respect to independent claims 7, 12 and 13, each of these claims likewise 
recites the dynamic modification of a cluster communication parameter. As discussed above in 
connection with claim I, Moiin merely discloses, at the most, changes to membership-related 
parameters such as cluster size and a cluster list. Nothing in Moiin discloses or suggests the 
dynamic modification of a parameter used in cluster communications. Accordingly, claims 7, 12 
and 13 are all novel over Moiin for the same reasons as claim 1. Reversal of the Examiner's 
rejections of claims 7, 12 and 13 are therefore respectfully requested. 

Moreover, the Examiner has failed to establish motivation in the art to modify Moiin as 
would be required to establish obviousness as to any of these claims. Allowance of each of 
independent claims 7, 12 and 13, and of claims 8-11 and 14-18 which depend therefrom, are 
therefore respectfully requested. 

Claims 8-11 and 14-18 

Claims 8-11 and 14-18 are not separately argued. 
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Claim 19 

Next with respect to independent claim 1 9, this claim generally recites a method of 
dynamically modifying a heartbeat parameter in a node among a plurality of nodes in a clustered 
computer system. In addition, among other features, claim 19 specifically recites the concept of 
sending a heartbeat message from a first node to a second node, where the heartbeat message 
indicates that a heartbeat parameter is to be modified, as well as the concept that modification of 
the heartbeat parameter in the first node is deferred until receipt of an acknowledgment message 
from the second node that indicates that the heartbeat parameter has been modified in the second 
node . 

In rejecting claim 19, the Examiner again relies on Moiin y and in particular, the disclosure 
at col. 14, lines 26-34 which discuss the sending of heartbeat messages. However, as discussed 
above in connection with claim 2, Moiin does not disclose dynamically modifying a heartbeat 
parameter. Furthermore, the cited passage of Moiin does not disclose the content of a heartbeat 
message or an acknowledgment thereto, and specifically fails to disclose that a heartbeat message 
may include an indication that a heartbeat parameter is to be modified, or that an 
acknowledgment message may include an indication that a heartbeat parameter has been 
modified, as would be required to anticipate claim 19. 

The disclosure related to the reconfiguration messages that the Examiner also cites 
against claim 19 do not strengthen the Examiner's arguments. Even under the overly-broad 
readings taken by the Examiner, reconfiguration messages cannot be considered to be "heartbeat 
messages" as these messages are infrequently communicated messages that initiate changes in 
membership in a cluster, and have nothing to do with the more regular, periodic heartbeat 
messages that are conventionally sent out in a cluster. Heartbeat messages are well understood 
even by Moiin to be different from reconfiguration messages, as evidenced by col. 14, lines 29- 
34 ("For example, keep alive thread 1014, communication timeout thread 1012, and receiver 
threads 1006 can use kernel timeout interrupts to periodically send and receive conventional 
heartbeat messages to periodically indicate that node 0 is operational and in communication with 
each of the nodes of the current cluster" {emphasis added)). 
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The Examiner also attempts to argue in the Final Office Action that Applicants arguments 
are directed merely to language in the preamble. However, the Examiner apparently ignores 
Applicants arguments focused on the body of the claim, specifically the language "sending a 
heartbeat message . . . indicating that a heartbeat parameter is to be modified." As Applicants 
have noted above, this concept (present in the body of the claim, and not in the preamble) is not 
disclosed in Moiin. Indeed, the Examiner completely ignores this language in his response to 
Applicants' arguments in the Final Office Action. 

Applicants therefore respectfully submit that claim 19 is novel over Moiin, and that the 
rejection of claim 19 should be reversed. Moreover, Applicants respectfully submit that the 
Examiner has failed to establish any motivation to modify Moiin to provide, within a heartbeat 
message, an indication that a heartbeat parameter is to be modified. As a result, claim 19 is also 
non-obvious over Moiin. Allowance of claim 19, as well as of claims 20-25 which depend 
therefrom, is therefore respectfully requested. 

Claims 20 and 27 

Claim 20 depends from claim 19, and additionally recites the concept of determining 
whether modifying the heartbeat parameter on a first node requires synchronization with a second 
node. Claim 27 is similar to claim 20, but depends from claim 26. As discussed, for example, at 
p. 19, lines 8-24 of the Application, changes to some heartbeat parameters may not need to be 
synchronized between nodes in a cluster, and as a result, claims 20 and 26 describe functionality 
that enables synchronization to be avoided for a heartbeat parameter modification that does not 
require it. 

The passages mMoiin cited by the Examiner (col. 14, lines 10-15 and 26-34; col. 2, lines 
29-37 and Figs. 4-6) do not disclose any functionality that is even arguably analogous to the 
functionality recited in claims 20 and 27. Accordingly, Applicants submit that the Examiner has 
failed to meet the burden required to establish anticipation of these claims, and that the rejections 
of these claims should be reversed. 
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Claims 21 and 28 

Claim 21 depends from claim 20, and additionally recites the concept of determining 
whether a heartbeat parameter is local or global in nature. Claim 28 is similar to claim 21 , but 
depends from claim 27. 

The passages in Moiin cited by the Examiner (col. 14, lines 19-21 and col. 5, lines 18-30) 
do not disclose any functionality that is even arguably analogous to the functionality recited in 
claims 21 and 28. Accordingly, Applicants submit that the Examiner has failed to meet the 
burden required to establish anticipation of these claims, and that the rejections of these claims 
should be reversed. 

Claim 22 

Claim 22 is not separately argued. 

Claims 23-24 and 29-30 

Claim 23 depends from claim 22, and recites in part the concept of setting a change 
request indicator in a heartbeat message to indicate that a heartbeat parameter is to be modified. 
Claim 24 depends from claim 23 and additionally recites modifying a heartbeat parameter only 
after receiving a heartbeat acknowledgment message with a set change request indicator. Claims 
29 and 30 recite similar subject matter, but depend ultimately from claim 26. 

The passages in Moiin cited by the Examiner with reference to change request indicators 
(col 6, lines 35-42 and col. 7, lines 31-61) do not disclose any functionality that is even arguably 
analogous to the functionality recited in these claims. Apparently, the Examiner considers the 
indications of prospective cluster sizes in reconfiguration messages to correspond to change 
request indicators; however, the indications of cluster size fall short of anticipating the concept of 
a change request indicator. 

First, these indicators are provided in heartbeat messages in the rejected claims. The 
cluster sizes in Moiin are communicated in reconfiguration messages, which as noted above, are 
recognized by Moiin as being different from heartbeat messages. 
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Second, the fact that the size of a prospective cluster is communicated in a message may 
indicate to a node that the membership is changing is insufficient to teach a specific change 
request indicator in a message. Indeed, it is only after a node compares its local information with 
the cluster size communicated by another node that the node can ascertain whether a change is 
occurring. The cluster size, itself, therefore fails to serve as an indicator of a change request. 

Accordingly, Applicants submit that the Examiner has failed to meet the burden required 
to establish anticipation of these claims, and that the rejections thereof should be reversed. 

Claim 25 

Claim 25 is not separately argued. 

Claims 26 and 31 

Next turning to independent claims 26 and 31, each of these claims likewise recites the 
dynamic modification of a heartbeat parameter through the use of heartbeat messages that 
indicate that a heartbeat parameter is to be modified and acknowledgment messages that indicate 
that a heartbeat parameter has been modified. As discussed above in connection with claim 19, 
these features are not disclosed by Moiin, and as such, these claims are novel over Moiin for the 
same reasons as presented above for claim 19. The Examiner's rejections of these claims should 
therefore be reversed. Moreover, Applicants respectfully submit that the Examiner has failed to 
establish any motivation to modify Moiin to provide, within a heartbeat message, an indication 
that a heartbeat parameter is to be modified. As a result, claims 26 and 31 are also non-obvious 
over Moiin. Allowance of claims 26 and 31, as well as of claims 27-30 which depend therefrom, 
is therefore respectfully requested. 

IX. CONCLUSION 

In conclusion, Applicants respectfully request that the Board reverse the Examiner's 
rejections of claims 1-31, and that the Application be passed to issue. If there are any questions 
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regarding the foregoing, please contact the undersigned at 5 13/241-2324. Moreover, if any other 
charges or credits are necessary to complete this communication, please apply them to Deposit 
Account 23-3000. 

Respectfully submitted, 

WOOD, HERRON & EVANS, LXP. 

Date: 

Scott A. Stinebruner 
2700 Carew Tower Reg. No. 38,323 

441 Vine Street 
Cincinnati, Ohio 45202 
(513) 241-2324 
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Claims Appendix : Claims on Appeal 09/694,586 

X. CLAIMS APPENDIX: CLAIMS ON APPEAL (SIN 09/694,586) 

1 . (Original) A method of dynamically modifying a cluster communication parameter in 
a clustered computer system, the method comprising: 

(a) initiating a cluster communication parameter modification by transmitting a 
message to a plurality of nodes in the clustered computer system; 

(b) locally confirming, within each node, receipt of the message by each of the 
plurality of nodes; 

(c) in response to confirming receipt of the message by each of the plurality of 
nodes, invoking a local cluster communication parameter modification operation on each 
node; 

(d) transmitting from each node a status of the local cluster communication 
parameter modification invoked on that node; 

(e) locally detecting, within each node, an unsuccessful status for the local cluster 
communication parameter modification on any node; and 

(f) in response to detecting an unsuccessful status for any node, locally undoing, 
in each node for which the local cluster communication operation was performed, the 
local cluster communication parameter modification operation performed on that node. 

2. (Original) The method of claim 1 , wherein the cluster communication parameter 
comprises a heartbeat parameter. 

3. (Original) The method of claim 1, wherein the cluster communication parameter is 
selected from the group consisting of heartbeat message time out, heartbeat acknowledgment 
message time out, heartbeat frequency or interval, heartbeat failure threshold, heartbeat 
acknowledgment failure threshold, receive/send timer ratio, maximum fragment size, message 
retry timer value, maximum message retry time, send queue overflow threshold, message send 
window size, and combinations thereof 
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Claims Appendix : Claims on Appeal 09/694 1 5 86 

4. (Original) The method of claim 1, wherein locally confirming receipt of the message 
by each of the plurality of nodes includes participating in an ACK round responsive to receipt of 
the message. 

5. (Original) The method of claim 1, wherein transmitting from each node a status of the 
local cluster communication parameter modification invoked on that node is performed during an 
ACK round performed subsequent to invoking the local cluster communication parameter 
modification operation. 

6. (Original) The method of claim 1, wherein transmitting the message, confirming 
receipt of the message, and transmitting the status are performed via multicast messages. 

7. (Original) An apparatus, comprising: 

(a) a memory; and 

(b) a program resident in the memory, the program configured to dynamically 
modify a cluster communication parameter on a local node among a plurality of nodes in 
a clustered computer system, the program configured to locally confirm, for the local 
node, successful receipt of an initiation message by each of the plurality of nodes, and a 
status for a local cluster communication parameter modification operation performed by 
each of the plurality of nodes, the program further configured to undo a local cluster 
communication parameter modification operation performed on the local node in 
response to detection of an unsuccessful status for a local cluster communication 
parameter modification on any node. 

8. (Original) The apparatus of claim 7, wherein the program is further configured to 
locally confirm receipt of an initiating message by each of the plurality of nodes. 

9. (Original) The apparatus of claim 8, wherein the program is configured to locally 
confirm receipt of the initiating message by each of the plurality of nodes by participating in an 
ACK round responsive to receipt of the message. 
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Claims Appendix : Claims on Appeal 09/694,586 

10. (Original) The apparatus of claim 7, wherein the program is further configured to 
transmit from the local node a status of the local cluster communication parameter modification 
operation. 

1 1 . (Original) The apparatus of claim 10, wherein the program is configured to transmit 
the status during an ACK round performed subsequent to invocation of the local cluster 
communication parameter modification operation. 

12. (Original) A clustered computer system, comprising: 

(a) a plurality of nodes coupled to one another over a network; and 

(b) a plurality of programs, each local to a node among the plurality of nodes, 
each program configured to dynamically modify a cluster communication parameter on 
its respective local node, each program further configured to locally confirm, for its 
respective local node, successful receipt of an initiation message by each of the plurality 
of nodes, and a status for a local cluster communication parameter modification operation 
performed by each of the plurality of nodes, and each program further configured to undo 
a local cluster communication parameter modification operation performed on its 
respective local node in response to detection of an unsuccessful status for a local cluster 
communication parameter modification on any node. 



13. (Original) A program product, comprising: 
^ (a) a program configured to dynamically modify a cluster communication 

parameter on a local node among a plurality of nodes in a clustered computer system, the 
program configured to locally confirm, for the local node, successful receipt of an 
initiation message by each of the plurality of nodes, and a status for a local cluster 
communication parameter modification operation performed by each of the plurality of 
nodes, the program further configured to undo a local cluster communication parameter 
modification operation performed on the local node in response to detection of an 
unsuccessful status for a local cluster communication parameter modification on any 
node; and 
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Claims Appendix : Claims on Appeal 09/694 , 5 86 
(b) a signal bearing medium bearing the program. 

14. (Original) The program product of claim 13, wherein the signal bearing medium 
includes at least one of a transmission medium and a recordable medium. 

15. (Original) The program product of claim 13, wherein the program is further 
configured to locally confirm receipt of an initiating message by each of the plurality of nodes. 

16. (Original) The program product of claim 15, wherein the program is configured to 
locally confirm receipt of the initiating message by each of the plurality of nodes by participating 
in an ACK round responsive to receipt of the message. 

17. (Original) The program product of claim 13, wherein the program is further 
configured to transmit from the local node a status of the local cluster communication parameter 
modification operation. 

18. (Original) The program product of claim 17, wherein the program is configured to 
transmit the status during an ACK round performed subsequent to invocation of the local cluster 
communication parameter modification operation. 

19. (Original) A method of dynamically modifying a heartbeat parameter in a node 
among a plurality of nodes in a clustered computer system, the plurality of nodes including first 
and second nodes, the first node configured to send a heartbeat message to the second node, and 
the second node configured to send an acknowledgment message to the first node in response to 
receiving the heartbeat message, the method comprising: 

(a) sending a heartbeat message from the first node to the second node, the 
heartbeat message indicating that a heartbeat parameter is to be modified; and 

(b) deferring modification of the heartbeat parameter in the first node until receipt 
of an acknowledgment message sent from the second node to the first node that indicates 
that the heartbeat parameter has been modified in the second node. 
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Claims Appendix : Claims on Appeal 09/694 J 86 

20. (Original) The method of claim 19, further comprising determining whether 
modifying the heartbeat parameter on the first node requires synchronization with the second 
node. 

2L (Original) The method of claim 20, wherein determining whether modifying the 
heartbeat parameter on the first node requires synchronization with the second node further 
comprises determining whether the heartbeat parameter is local or global in nature. 

22. (Original) The method of claim 19, further comprising, in response to receiving the 
heartbeat message with the second node, sending an acknowledgment message from the second 
node to the first node, the acknowledgment message indicating whether the heartbeat parameter 
has been modified in the second node. 

23. (Original) The method of claim 22, wherein each of sending the heartbeat message 
and sending the heartbeat acknowledgment message includes accessing a heartbeat message 
record that includes a change request indicator, the method further comprising: 

(a) prior to sending the heartbeat message that indicates that the heartbeat 
parameter is to be modified, setting the change request indicator in the heartbeat message 
record; and 

(b) prior to sending the heartbeat acknowledgment message that indicates 
whether the heartbeat parameter has been modified in the second node, selectively setting 
or clearing the change request indicator in the heartbeat message record. 

24. (Original) The method of claim 23, wherein deferring modification of the heartbeat 
parameter in the first node until the acknowledgment message indicates that the heartbeat 
parameter has been modified in the second node includes modifying the heartbeat parameter in 
the first node only after receiving a heartbeat acknowledgment message with a set change request 
indicator. 
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25. (Original) The method of claim 19, further comprising: 

(a) modifying the heartbeat parameter in the second node; and 

(b) modifying the heartbeat parameter in the first node after receipt of an 
acknowledgment message sent from the second node to the first node that indicates that 
the heartbeat parameter has been modified in the second node. 

26. (Original) An apparatus, comprising: 

(a) a memory; and 

(b) a program resident in the memory and configured to dynamically modify a 
heartbeat parameter in a first node among a plurality of nodes in a clustered computer 
system by sending a heartbeat message to a second node among the plurality of nodes that 
indicates that the heartbeat parameter is to be modified and thereafter deferring 
modification of the heartbeat parameter in the first node only after receiving an 
acknowledgment message from the second node indicating that the heartbeat parameter 
has been modified in the second node. 

27. (Original) The apparatus of claim 26, wherein the program is further configured to 
determine whether modifying the heartbeat parameter on the first node requires synchronization 
with the second node. 

28. (Original) The apparatus of claim 27, wherein the program is configured to 
determine whether modifying the heartbeat parameter on the first node requires synchronization 
with the second node by determining whether the heartbeat parameter is local or global in nature. 

29. (Original) The apparatus of claim 26, wherein the program is configured to send the 
heartbeat message by accessing a heartbeat message record that includes a change request 
indicator, and wherein the program is further configured to set the change request indicator in the 
heartbeat message record prior to sending the heartbeat message that indicates that the heartbeat 
parameter is to be modified. 
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30. (Original) The apparatus of claim 2% wherein the program is configured to defer 
modification of the heartbeat parameter in the first node until the acknowledgment message 
indicates that the heartbeat parameter has been modified in the second node by modifying the 
heartbeat parameter in the first node only after receiving a heartbeat acknowledgment message 
with a set change request indicator. 

31. (Original) A program product, comprising: 

(a) a program configured to dynamically modify a heartbeat parameter in a first 
node among a plurality of nodes in a clustered computer system by sending a heartbeat 
message to a second node among the plurality of nodes that indicates that the heartbeat 
parameter is to be modified and thereafter deferring modification of the heartbeat 
parameter in the first node only after receiving an acknowledgment message from the 
second node indicating that the heartbeat parameter has been modified in the second 
node; and 

(b) a signal bearing medium bearing the program. 
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